Rather than picking up the telephone, more and more customers choose to use the Internet to obtain tickets to sporting and various other entertainment events, to purchase goods from a store's inventory, and to secure their restaurant reservations. Through various websites, customers can enjoy easy access to information about restaurants and other events and book reservations quickly and easily. Efficiency is increased and time is saved when customers who wish to make restaurant reservations can do so online, in real-time, without the inconvenience of first searching for the restaurant's phone number and then placing a call directly to the restaurant to determine if there is an available “slot” (i.e., an available table of a certain size and for a certain time) to accommodate the customer's party.
One such practical use, although by no means the only use, is exemplified by customers who travel, either for business or pleasure. Such customers may want to book reservations at restaurants well in advance of their visit. Websites that facilitate real-time online restaurant reservations may allow the customer to enter the name of the geographic region they are planning to visit, the name of the restaurant they wish to dine at (if known), and the date and time they wish to dine along with the size of their party. The website may then determine if that particular restaurant can accommodate the customer and his or her party at the requested time. Other search criteria may include preferred cuisine, price, similar restaurants, restaurants close in proximity to an address, restaurants recommended by people who dined at this a specific restaurant, and other promotions offered by restaurants in the area.
Once a restaurant is selected, the website accesses the restaurant's database, which contains the restaurant “inventory”, i.e., the number of tables in the restaurant, the seating capacity of the tables, and which of those tables that have been reserved for a particular time slot. This may be a simple task if the customer has specified the name of the restaurant. However, if the customer simply types in a type of cuisine, e.g., “Italian Food”, in a geographical region, e.g. “Atlanta, Ga.”, the website must query the inventory database of each participating Italian restaurant in Atlanta, perhaps several hundred or thousand. The query would be identical, e.g. “do you have an available table for four, between 7 and 7:30 PM on the evening of July 12th?” The website may send 1,500 identical real-time messages and receive 1,500 real-time responses. Needless to say, this is not an efficient way of determining availability since the volume of messages would increase linearly as restaurants are added. The speed and performance of the non-reservation functionality at each restaurant (e.g., wait list management, table management, database management) would degrade due to the increasing queries from patrons seeking to book an available table. In addition, the performance of the restaurant searches themselves would degrade as an instantaneous function of the number of other concurrently active searches. Each query requesting a table would compete with other similar queries interested in booking an available table at the selected restaurant. Finally, the performance of the non-search related functionality inherent to the system also degrades, preventing restaurant employees from accessing those capabilities in a timely fashion.
Indeed, such an online reservation system may store complete restaurant table inventory information directly in the website database. While this serves to provide an entire backup database of all tables at participating restaurants, it also puts a severe strain on system resources. In this scenario, the website database is consulted upon each user inquiry for a particular restaurant. The website must search through its database for each restaurant and determine whether a particular table capacity has already been reserved for a particular time slot. A great deal of the inventory information stored on the website database is never checked and is irrelevant in determining if a table for a specified party size and time is available. For example, the user does not care if 2, 3, or 4 tables of four are available for the user's party at the requested time. The user is only interested if one table is available that can accommodate his/her party size. Or, if the user needs two tables of four, he/she need not be concerned if more than two tables of four are available at the chosen restaurant at the desired time. Thus, this approach would needlessly store a great deal of unnecessary inventory information, which, if the user's status request is to be satisfied, must be checked upon each and every user inquiry.
Further, this approach is inefficient because a message is sent to the central server every time there is change at the restaurant database level (e.g., every time a reservation is booked). These constant and unnecessary network messages waste bandwidth and degrade the performance of the network.
It is therefore desirable to have a method and system that reduces the message “traffic” between the host website and the restaurant inventory databases, decreases bandwidth demands upon the network, and decreases CPU demands on the restaurant servers.
It is further desirable to have a method and system that utilizes a caching scheme at the website to reduce the need for real-time searching of the restaurant databases and, thereby, increase overall online reservation searching efficiency.
It is also desirable to have a method and system that stores only “summary” information on a website's server, rather than complete table inventory, where the summary information provides information regarding whether a table of a specified size is available rather than how many tables of the requested size are available. The existence of summary-level information will minimize network messages, prevent the central server from being flooded by network message traffic, use less memory, and conserve system resources. It is further desirable to have a method and system that places the cache server at a location different from the reservation server and the website server.